Gold Medal Software 2/Gold Medal Software Volume 2 (Gold Medal) (1994).iso/utils/exc27.arj/EXC.HST

Text File | 1993-08-15 | 14KB | 293 lines

REVISIONS FOR VERSION 1.1 OF EXC.EXE

Many thanks to the few users who have reported problems and/or suggested
enhancements.  If you don't report them and I don't find them, they don't
get fixed.


1. I apologize for the EXC.DOC file.  In my rush to get it documented and
   uploaded, I neglected to spell check or proofread it.  It was terrible.
   I hope it is much more readable now.

2. Leading and trailing TAB characters (hex 09) were not being removed from
   script lines, causing invalid command messages.

3. There appears to be a need in the user community to repeat commands,
   groups of commands and keys a known number of times to allow them to
   write smaller scripts.

   Added "ON n label".  This is a powerfull loop control command similar
   to the logic used in FOR statements common in many programming languages.

   Added a repeat number that can be added to the end of a KEY command.  The
   key that is specified will be repeated as many times as specified.  For
   instance, "KEY <TAB> 5" stuffs five tabs into the keyboard buffer.

4. Fixed a problem where certain invalid key mnemonics were not generating
   error messages.

5. If you loop through SEARCH commands looking for multiple possible messages
   that could occur, each time the timer interrupt is invoked (18.2/sec) the
   entire screen is read, reformatted to remove attributes and searched for
   each SEARCH in the loop.  WAITFOR and WAITSCR have built-in one second
   delays between screen reads to minimize this overhead.

   One solution is to stick a DELAY in the loop, but if you do this between
   each SEARCH, execution of the script will slow down dramatically.

   I added a READ command that will read the screen and do nothing else.

   I then added a LOOK command that searches the screen buffer that was last
   read by a READ, SEARCH, WAITFOR or WAITSCR command.  It's just like the
   SEARCH command without reading the screen prior to the search.

   EXAMPLE 1:                   EXAMPLE 2:          EXAMPLE 3:

   :Loop                        :Loop               :Loop
     SEARCH "Continue?"           READ                SEARCH "Continue?"
     IFY Continue                 LOOK "Continue?"    IFY Continue
     LOOK "ERROR:"                IFY Continue        LOOK "ERROR:"
     IFY Error                    LOOK "ERROR:"       IFY Error
     GOTO Loop                    IFY Error           DELAY 1
   :Continue                      DELAY 1             GOTO Loop
     .                            GOTO Loop         :Continue
     .                          :Continue             .
   :Error                         .                   .
     .                            .                 :Error
     .                          :Error                .
                                  .                   .
                                  .

   In the above examples, Example 1 shows how you would have intuitavely
   coded the script in version 1.0.  Adding a DELAY 1 at the end of the
   loop would have helped performance, but two screen reads would be per-
   formed each second.  Example two demonstrates how READ and LOOK could
   be used to make a very efficient loop.  Example 3 shows that, since
   a READ followed by a LOOK is equal to a SEARCH, so the third example
   is the best because it takes two iterations of the interrupt to process
   each command in the script.  The first iteration reads and formats the
   command and the second executes it.

6. Installed COMMAND.COM as the default program name on the command line.

7. Modified QUIT and end0of-script logic to issue EXIT if COMMAND.COM was
   invoked.


REVISIONS FOR VERSION 1.2 OF EXC.EXE

Many thanks to the few users who have reported problems and/or suggested
enhancements.  If you don't report them and I don't find them, they don't
get fixed.

1.  Timeout processing was malfunctioning for WAITSCR.  Fixed.

2.  READ and LOOK were mistakenly included in v1.1 documentation, but are
    not actually implemented until v1.2.

3.  In 1.1 and older, the maximum screen size was 80x50.  EXC returned an
    error if you were in a larger screen mode.  Also I had to obtain a 8,000
    byte buffer (character + attribute) to read the 80x50 screen regardless
    of the text mode you were using.

    I must preallocte the screen buffer because the spawned program may
    consume all remaining memory.  I can't just use the current video
    settings since the spawned program may change the text mode.

    I have added a command "SCRMAX cols rows" that allows preallocation of
    buffers for large screen sizes.  The default, if SCRMAX is not in the
    script, will be the rows and columns of the text mode in use when EXC is
    invoked.  Please read the documentation under SCRMAX for full usage
    instructions and the implications and penalties involved in reserving
    large screen buffers.

    This prevents wasting memory in screen sizes smaller than 80x50 and
    allows EXC to fully function on screens larger than 80x50.

    Supported screen widths are from 40-200 columns.  Supported screen
    heights are from 20-100 rows.

1.  I no longer read the video attribute when I read the screen, thus
    cutting screen buffer requirements in half.

2.  To minimize problems with spawned programs which may also be using
    timer interrupts, I have broken down the execution of many commands into
    parts executed in multiple timer interrupts.

3.  For the same reason as for the previous changes, I have cut the time
    down for error beeps and for the delay the beeps.  Errors, which emitted
    4 beeps now only beep twice.

4.  Timeouts, which emitted 3 beeps now emit no beep.  If you need
    to know when a timeout occurred, place a beep in your script where
    needed.  This is primarily because intentional timeouts could be quite
    common and don't require user attention.

5.  Modified DELAY and TIMEOUT processing to compare against the system
    clock instead of using countdown timers via INT 1C.  This gives more
    accurate timing since 1C may or may not be called 18.2 times per
    second, depending on how long the interrupt handler had it tied up.

6.  I have added key combinations that will terminate (LEFT and RIGHT SHIFT
    keys)and pause/resume (SCROLL LOCK) the execution of scripts.  Unlike
    pressing the PAUSE key, SCROLL LOCK pauses only script execution and not
    the spawned program.  The PAUSE key will suspend both.

7.  I have insterted code that detects pause state and suspends all delays
    until pause state is exited.  For example, if you press the PAUSE key
    5 seconds into a 10 second delay, when you press a key to resume
    processing, you will still have 5 seconds of delay before the next command
    is executed.  No new commands will be initiated during pause state.

8.  Fixed a problem that limited total memory allocations to 64k and sometimes
    caused system halt if more was requested for scripts, screen or spawned
    program.

9.  Enhanced functionality and script debugging by adding the following 14
    new commands:

    TICK           CLEAR           PAUSE            TIME
    WINMAX         WINCOLS         WINROWS          CURSOR
    SHOWAT         SHOW            SHOWWIN          LOCATE
    HIDEWIN        TYPFILE

10. Rearranged the documentation so that commands are listed alphabetically.
    Added more examples.  Added more in-depth explanations of operational
    considerations that might effect EXC's performance or lack thereof.

11. Included the script that I use for testing EXC in the distribution
    files.  This provides at least one example of every command EXC
    recognizes.

12. Allow entry of quotes within a string by substituting \q for ".


Version 2.0a

   The programs in version 2.0a are identical to those in version 2.0, except
for the registration remider screen.  The reminder screen and documentation
have been updated to include instructions on how to register EXC online via
CompuServe's SWREG section.


REVISIONS FOR VERSION 2.1 OF EXC.EXE


1.  Recompiled EXC in 8086/8088 code so that it could be used on XT class
    machines.  Performance impact on 286 and above processors is negligible.

2.  Added a parameter to the QUIT instruction.  Normally on exit, EXC returns
    the return code of the executed program.  If a number (0-255) is
    specified with the QUIT command, that value is returned as the DOS
    ERRORLEVEL return code instead of what was passed from the spawned
    program.

    An example of why you would want to set a return code:

       I use EXC to control PROCOMM PLUS to execute a script that synchro-
       nizes my clock with the Naval Observatory.  I need to know if it
       fails.

       I can detect the error with my EXC script, but when I exit PCPLUS,
       PCPLUS always returns a return code of 255.  Using the QUIT nn format,
       I can set a return code of 1 on error and 0 when there is no error.

3. After a PRTSC key mnemonic was executed, the script processor failed
   to continue to the next line and terminated at that point.


REVISIONS FOR VERSION 2.2 OF EXC.EXE

1.  Added support for using environment variables in any command string
parameter.

2.  When you tried to pass a parameter to the spawned program that
contained spaces and was enclosed in quotes, the parameter arrived to
the spawned program broken down into multiple one-word parameters.  While
EXC was passing it as a single parameter, DOS was breaking it down.  I had
to make sure each parameter passed to the spawned program was enveloped
in quotes in order to assure proper operation.

3.  EXC could have been copying one or more input parameters to uninitialized
string pointers.  This means that the parameters could have been copied
anywhere in memory.  These storage violations could cause random errors
varying in degree of nastiness and symptioms.  These pointers now point to
a fixed array of allocated memory.

    If you experienced random, strange occurances after using EXC, this could
be the cause.  It could also cause QEMM exception 13 errors.  I examine my
code very closely for these nastiest of bugs, but with the flexibilty of
data types, pointers and arrays used in C++, it is nearly impossible to find
them until a repeatable error can be found.

    If you experience unusual problems after using EXC v2.2, try your best to
repeat them.  If you can in any way recreate the problem or narrow down the
activity that causes the problem, let me know.  EXC is becoming a very stable
product now, thanks to your help.  In this type of program it is impossible
to test every combination that users will use.


REVISIONS FOR VERSION 2.3 OF EXC.EXE

Version 2.2 attempted to properly pass quoted parameters by enclosing all
parameters in quotes.  While this worked fine on Borland C and C++ programs,
if the spawned program was PASCAL or assembler, it received the parameter with
the quotes.  Since most programmers were not expecting quoted parameters,
they had no code to handle them.  Borland C always remoed the quotes before
a program could access the parameters.  This means that EXC VERSION 2.2 DID
NOT WORK WHEN MOST PASCAL AND ASSEMBLER PROGRAMS WERE INVOKED.

I now check each parameter for a space, |, < or >.  If it contains one of
these, I assume the input string was quoted and pass it on with surrounding
quotes.  All other parameters are passed as-is.

\" can no longer be used to imbed quotes in a parameter to be passed to a
spawned program.  \q must be used instead.


REVISIONS FOR VERSION 2.4 OF EXC.EXE

1.  Although EXC processed correctly, sometimes an erroneous warning message
    would appear at the end of the job stating that the script had failed to
    complete and claiming to have stopped at the last command in the script.
    The last command had, in fact, been executed.

2.  Instead of assuming COMMAND.COM for the default when no spawned program
    is specified, I now use the program specified in the COMSPEC environment
    variable.  If COMPSEC is not found in the environment, I then use
    COMMAND.COM.



REVISIONS FOR VERSION 2.5 OF EXC.EXE

1. It appears that a few applications and at least one well known appli-
   cation development package actually write binary zeros to certain parts of
   screen memory.  These appear as spaces on the screen but are actually read
   as binary zeros when EXC reads screen memory.  When EXC is searching the
   video memory for a string, it uses a string search algorithm that is
   terminated at the first binary zero.  This is because C++ uses binary
   zeros to terminate strings.

   The result is that certain string text would be displayed on the screen
   but would not be located by EXC because the search was terminated
   prematurely.

   EXC now replaces any binary zeros in the screen buffer text with spaces.
   This allows the search to perform as expected.

2. The ON function did not work properly when the counter was more than 9.
   This has been corrected.


REVISIONS FOR VERSION 2.6 OF EXC.EXE

 The DELAY and TICK commands did not always work properly if the wait
 state was in effect at midnight when the system timer clock rolls over
 to zero.  EXC has been modified to compensate for this possibility.

Version 2.6a:

 We are moving.  Updated registration screen and documentation to show
 new address.  No functional changes.